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Abstract 


The Network Time Protocol (NTP) can operate in several modes. Some of these modes are based 
on the receipt of unsolicited packets and therefore require the use of a well-known port as the 
local port. However, in the case of NTP modes where the use of a well-known port is not 
required, employing such a well-known port unnecessarily facilitates the ability of attackers to 
perform blind/off-path attacks. This document formally updates RFC 5905, recommending the 
use of transport-protocol ephemeral port randomization for those modes where use of the NTP 
well-known port is not required. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9109. 
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This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
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with respect to this document. Code Components extracted from this document must include 
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1. Introduction 


The Network Time Protocol (NTP) is one of the oldest Internet protocols and is currently specified 
in [RFC5905]. Since its original implementation, standardization, and deployment, a number of 
vulnerabilities have been found both in the NTP specification and in some of its implementations 
[NTP-VULN]. Some of these vulnerabilities allow for blind/off-path attacks, where an attacker can 
send forged packets to one or both NTP peers to achieve Denial of Service (DoS), time shifts, or 
other undesirable outcomes. Many of these attacks require the attacker to guess or know at least 
a target NTP association, typically identified by the tuple {srcaddr, srcport, dstaddr, dstport, 
keyid} (see Section 9.1 of [RFC5905]). Some of these parameters may be known or easily guessed. 


NTP can operate in several modes. Some of these modes rely on the ability of nodes to receive 
unsolicited packets and therefore require the use of the NTP well-known port (123). However, for 
modes where the use of a well-known port is not required, employing the NTP well-known port 


Gont, et al. Standards Track Page 2 


RFC 9109 NTP Port Randomization August 2021 


unnecessarily facilitates the ability of attackers to perform blind/off-path attacks (since 
knowledge of the port numbers is typically required for such attacks). A recent study [NIST-NTP] 
that analyzes the port numbers employed by NTP clients suggests that numerous NTP clients 
employ the NTP well-known port as their local port, or select predictable ephemeral port 
numbers, thus unnecessarily facilitating the ability of attackers to perform blind/off-path attacks 
against NTP. 


BCP 156 [RFC6056] already recommends the randomization of transport-protocol ephemeral 
ports. This document aligns NTP with the recommendation in BCP 156 [RFC6056] by formally 
updating [RFC5905] such that port randomization is employed for those NTP modes for which 
the use of the NTP well-known port is not needed. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


3. Considerations about Port Randomization in NTP 


The following subsections analyze a number of considerations about transport-protocol 
ephemeral port randomization when applied to NTP. 


3.1. Mitigation against Off-Path Attacks 


There has been a fair share of work in the area of blind/off-path attacks against transport 
protocols and upper-layer protocols, such as [RFC4953] and [RFC5927]. Whether the target of the 
attack is a transport-protocol instance (e.g., TCP connection) or an upper-layer protocol instance 
(e.g., an application-protocol instance), the attacker is required to know or guess the five-tuple 
{Protocol, IP Source Address, IP Destination Address, Source Port, Destination Port} that identifies 
the target transport-protocol instance or the transport-protocol instance employed by the target 
upper-layer protocol instance. Therefore, increasing the difficulty of guessing this five-tuple 
helps mitigate blind/off-path attacks. 


As a result of these considerations, transport-protocol ephemeral port randomization is a best 
current practice (BCP 156) that helps mitigate off-path attacks at the transport layer. This 
document aligns the NTP specification [RFC5905] with the existing best current practice on 
transport-protocol ephemeral port selection, irrespective of other techniques that may (and 
should) be implemented for mitigating off-path attacks. 


We note that transport-protocol ephemeral port randomization is a transport-layer mitigation 
against blind/off-path attacks and does not preclude (nor is it precluded by) other possible 
mitigations for off-path attacks that might be implemented at other layers (e.g., [NTP-DATA- 
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MINIMIZATION)). For instance, some of the aforementioned mitigations may be ineffective 
against some off-path attacks [NTP-FRAG] or may benefit from the additional entropy provided 
by port randomization [NTP-security]. 


3.2. Effects on Path Selection 


Intermediate systems implementing the Equal-Cost Multipath (ECMP) algorithm may select the 
outgoing link by computing a hash over a number of values, including the transport-protocol 
source port. Thus, as discussed in [NTP-CHLNG], the selected client port may have an influence 
on the measured offset and delay. 


If the source port is changed with each request, packets in different exchanges will be more 
likely to take different paths, which could cause the measurements to be less stable and have a 
negative impact on the stability of the clock. 


Network paths to/from a given server are less likely to change between requests if port 
randomization is applied on a per-association basis. This approach minimizes the impact on the 
stability of NTP measurements, but it may cause different clients in the same network 
synchronized to the same NTP server to have a significant stable offset between their clocks. This 
is due to their NTP exchanges consistently taking different paths with different asymmetry in the 
network delay. 


Section 4 recommends that NTP implementations randomize the ephemeral port number of 
client/server associations. The choice of whether to randomize the port number on a per- 
association or a per-request basis is left to the implementation. 


3.3. Filtering of NTP Traffic 


In a number of scenarios (such as when mitigating DDoS attacks), a network operator may want 
to differentiate between NTP requests sent by clients and NTP responses sent by NTP servers. If 
an implementation employs the NTP well-known port for the client port, requests/responses 
cannot be readily differentiated by inspecting the source and destination port numbers. 
Implementation of port randomization for nonsymmetrical modes allows for simple 
differentiation of NTP requests and responses and for the enforcement of security policies that 
may be valuable for the mitigation of DDoS attacks, when all NTP clients in a given network 
employ port randomization. 


3.4. Effect on NAPT Devices 


Some NAPT devices will reportedly not translate the source port of a packet when a system port 
number (i.e., a port number in the range 0-1023) [RFC6335] is employed. In networks where such 
NAPT devices are employed, use of the NTP well-known port for the client port may limit the 
number of hosts that may successfully employ NTP client implementations at any given time. 


NOTES: 
NAPT devices are defined in Section 4.1.2 of [RFC2663]. 
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The reported behavior is similar to the special treatment of UDP port 500, which 
has been documented in Section 2.3 of [RFC3715]. 


ase of NAPT devices that will translate the source port even when a system port is 
ed, packets reaching the external realm of the NAPT will not employ the NTP well-known 
the source port, as a result of the port translation function being performed by the NAPT 


4. Update to RFC 5905 


The following text from Section 9.1 (Peer Process Variables) of [RFC5905]: 


dstport: UDP port number of the client, ordinarily the NTP port number PORT (123) 


is repla 


assigned by the IANA. This becomes the source port number in packets sent from this 
association. 


ced with: 


dstport: UDP port number of the client. In the case of broadcast server mode (5) and 
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symmetric modes (1 and 2), it SHOULD contain the NTP port number PORT (123) 
assigned by IANA. In the client mode (3), it SHOULD contain a randomized port 
number, as specified in [RFC6056]. The value in this variable becomes the source port 
number of packets sent from this association. The randomized port number SHOULD 
NOT be shared with other associations, to avoid revealing the randomized port to 
other associations. 


If a client implementation performs transport-protocol ephemeral port 
randomization on a per-request basis, it SHOULD close the corresponding socket/port 
after each request/response exchange. In order to prevent duplicate or delayed 
server packets from eliciting ICMP port unreachable error messages [RFC0792] 
[RFC4443] at the client, the client MAY wait for more responses from the server for a 
specific period of time (e.g., 3 seconds) before closing the UDP socket/port. 


NOTES: 


Randomizing the ephemeral port number on a per-request basis will better 
mitigate blind/off-path attacks, particularly if the socket/port is closed after each 
request/response exchange, as recommended above. The choice of whether to 
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randomize the ephemeral port number on a per-request or a per-association basis 
is left to the implementation, and it should consider the possible effects on path 
selection along with its possible impact on time measurement. 


On most current operating systems, which implement ephemeral port 
randomization [RFC6056], an NTP client may normally rely on the operating 
system to perform ephemeral port randomization. For example, NTP 
implementations using POSIX sockets may achieve ephemeral port randomization 
by not binding the socket with the bind() function or binding it to port 0, which 
has a special meaning of "any port". Using the connect() function for the socket 
will make the port inaccessible by other systems (that is, only packets from the 
specified remote socket will be received by the application). 


5. IANA Considerations 


This document has no IANA actions. 


6. Security Considerations 


The security implications of predictable numeric identifiers [PEARG-NUMERIC-IDS] (and of 
predictable transport-protocol port numbers [RFC6056] in particular) have been known for a 
long time now. However, the NTP specification has traditionally followed a pattern of employing 
common settings even when not strictly necessary, which at times has resulted in negative 
security and privacy implications (see, e.g., [NTP-DATA-MINIMIZATION]). The use of the NTP 
well-known port (123) for the srcport and dstport variables is not required for all operating 
modes. Such unnecessary usage comes at the expense of reducing the amount of work required 
for an attacker to successfully perform blind/off-path attacks against NTP. Therefore, this 
document formally updates [RFC5905], recommending the use of transport-protocol port 
randomization when use of the NTP well-known port is not required. 


This issue has been assigned CVE-2019-11331 [VULN-REPORT] in the U.S. National Vulnerability 
Database (NVD). 
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